Object-oriented creation breakpoints

ABSTRACT

A computer system, program product and method debug an object-oriented computer program by tracking the creation of objects by a plurality of creators (e.g., constructor methods) of a selected class. A user need not separately track each creator. Instead, a debugger identifies each creator and associates breakpoints with all or a user-specified subset of creators to facilitate tracking. Any of the breakpoints may then trigger a halting of execution during debugging. Moreover, in some instances it may be desirable to track the number of creations by all or the subset of the creators for the selected class during program execution until a user-specified condition is satisfied, whereupon program execution is terminated and debugging information is provided to the user.

CROSS-REFERENCE TO RELATED APPLICATIONS

This application is a continuation of U.S. patent application Ser. No.09/997,990 filed on Nov. 30, 2001 by Jeremy Alan Arnold et al., entitled“OBJECT-ORIENTED CREATION BREAKPOINTS” (ROC920010095US1), the disclosureof which is incorporated by reference herein.

FIELD OF THE INVENTION

The invention is generally related to computers and computer software.More specifically, the invention is generally related to debuggingcomputer programs, particularly in the field of object-orientedprogramming (OOP) technology.

BACKGROUND OF THE INVENTION

Debuggers are software tools that can be used to diagnose computerprograms and trace errors that arise during execution of the program.Debuggers are commonly used during the development of computer programs,to verify that a program under development operates as intended.

To support a debugger, information describing symbols and types in theprogram as well as information to map between source (human readable)and executable (machine readable) code is typically required. In thecase of compiled programs, a compiler can often produce thisinformation. This extra information, generally referred to as debugginginformation, enables a programmer to examine the types, variables anddata structures used in a program by name and to follow the execution ofthe program through the source code.

A number of debugging techniques can be used to enable a programmer toproperly analyze a program to detect points in the program where errorsoccur. One such technique is to put a breakpoint into the program, at apoint in the program where it is desirable for normal operation to besuspended automatically when certain conditions are met. Breakpoints areuseful for program testing. They are specified by programmers so thatinterim results of processing can be inspected, and then programs can berestarted to continue running normally.

In traditional debuggers, breakpoints are generally set on specificstatements within functions or methods; program execution is suspendedeach time the particular statement is called. In some environments,breakpoints may also be specified to be “conditional” so that executionis suspended by a breakpoint only when a particular condition associatedwith that breakpoint is met (e.g., after the breakpoint has been hitXtimes).

Statement-based breakpoints have been found to be very useful fordebugging program bugs and inefficiencies in traditional procedurallanguages that are sequential in nature. However, object-orientedlanguages, which have found increasing acceptability as programminglanguages, are based on quite a different concept.

Object-oriented programs are typically created using a set of languagetools, abstractions and constructs that support a particular form ofuser-defined type called a “class”. A class functions as a template, andassociates a collection of declared data with a set of operationscapable of being performed on that data, i.e., methods capable of beingcalled on the data. In an object-oriented program, objects aredynamically created during runtime using the classes as templates. Thecreation of a new object is often referred to as “instantiation,”whereby an object is an “instance” of a class.

A fundamental feature of object-oriented programming is that classes canbe related to one another by inheritance. The properties, behaviors,data and operations of a parent, or “base” class may be inheritedwithout modification by some child, or “derived” class, or the behavior,properties and operations may be selectively refined under the controlof the programmer in the derived class. The latter function is generallyreferred to as overriding. When defining a derived class, one may startby building on an existing base class that is similar to the one to becreated. The derived class inherits the implementation and behavior ofthe base class, including its methods and data, except as modified byoverriding amendments detailed in the derived class definition. Severalclasses can inherit the behaviors of a common parent, and in someobject-oriented languages a derived class may inherit from more than onebase class.

In a working program, objects are instantiated, or created as needed,and built from the templates defined by their respective classes. Duringruntime, it is often desirable to provide each new object with initialdata and/or initiate particular operations with the object. For thisreason, many object-oriented environments support special methods knownas constructors, or creators, that are called upon an object's creation.One or more constructor methods are typically defined in each class,while a default constructor method may be defined for some classes whenno explicit method is defined by the developer.

Many classes support multiple constructor methods that perform differentoperations based upon how many and what types of data values areprovided when creation of an object is desired. Constructor methodstypically specify particular call signatures that define the types ofdata values expected by those methods, so that, when object creation isinitiated, the data values supplied therewith can be analyzed to locatea matching constructor method, and the matching constructor method canthen be executed.

The use of multiple constructor methods for a class provides significantflexibility for programmers. However, the flexibility in object creationhas shortcomings during debugging of the computer program. For example,a programmer may desire to track when objects of a particular class havebeen created. Conventional breakpoints, which are statement based, couldbe set on statements in individual constructor methods so that theprogrammer is notified whenever a statement in a constructor method ishit during creation of an object. However, since more than oneconstructor may be responsible for creating these objects, a programmeris typically required to manually set a breakpoint on a statement ineach constructor method for a class. Manually setting a breakpoint on astatement in each constructor method, however, can be excessivelyburdensome and time consuming, and a distinct risk exists that aprogrammer may inadvertently forget to set a breakpoint in one of theconstructor methods, or forget to remove all of the breakpoints once thecondition has been adequately tested.

In addition, in some situations a programmer may wish to track thenumber of objects that are created for a particular class. As anexample, a programmer may wish to verify that an excessive number ofobjects are not created for a particular purpose, e.g., in a databaseenvironment, where a programmer might intend for no more than 10database connections to be active at any given time. Through the use ofmanually-set breakpoints in all constructor methods, a programmer couldmanually count the number of object creations; however, doing so couldbe unduly burdensome when tens, hundreds or thousands of objects arenormally created in a program.

Should halting execution after each object creation be undulyburdensome, a programmer could utilize conditional breakpoints in eachconstructor method to trigger only after a certain number of hits.However, given that each breakpoint would independently track the numberof times it was hit, and given that a programmer may not know therelative frequency that each constructor method for a particular objectis called, the programmer would still not be able to be notified after aspecific number of objects were created.

Consequently, a significant need exists for a method of debugging anobject-oriented computer program that facilitates the tracking of objectcreation operations during execution of the computer program.

SUMMARY OF THE INVENTION

The invention addresses these and other problems associated with theprior art by providing an apparatus, program product, and method ofdebugging an object-oriented computer program that facilitate thetracking of object creation operations by multiple creators for aparticular class defined in a computer program.

Consistent with one aspect of the invention, for example, anobject-oriented computer program is debugged using a plurality ofbreakpoints set for a plurality of creators for a class defined in theobject-oriented computer program. Specifically, in response to userinput, a plurality of creators for the class are identified, and aplurality of breakpoints are set on the identified creators. Executionof the object-oriented computer program is then halted during debuggingin response to hitting any of the plurality of breakpoints.

In some embodiments, the plurality of breakpoints are associated with a“creation” breakpoint, whereby user input received from a programmer orother user is directed toward performing operations on the creationbreakpoint, rather than the breakpoints set on the various creators.Functionality within the debugger thus manages the plurality ofbreakpoints as a collective group. Irrespective of whether the pluralityof breakpoints are associated with a common creation breakpoint,however, through the automated identification of creators for a class inresponse to user input, a programmer or other user is relieved of theburden of manually identifying creators and setting individualbreakpoints on the different creators for a particular class.

Consistent with another aspect of the invention, an object-orientedcomputer program is debugged by tracking a number of object creations ofa class defined in the object-oriented computer program duringdebugging, and halting execution of the object-oriented computer programin response to the number of object creations meeting a condition. Assuch, object creations are tracked across multiple creators.

These and other advantages and features, which characterize theinvention, are set forth in the claims annexed hereto and forming afurther part hereof. However, for a better understanding of theinvention, and of the advantages and objectives attained through itsuse, reference should be made to the Drawings, and to the accompanyingdescriptive matter, in which there is described exemplary embodiments ofthe invention.

BRIEF DESCRIPTION OF THE DRAWINGS

FIG. 1 is a block diagram of a computer system incorporating a debuggersupporting object-oriented creation breakpoints consistent with theinvention.

FIG. 2 is a block diagram of the principal software components in thedebugger of FIG. 1.

FIG. 3 is an exemplary data structure implementation for the breakpointtable of FIG. 2.

FIG. 4 is a flow diagram for a set breakpoint routine executed by thedebugger of FIG. 2.

FIG. 5 is a breakpoint hit routine executed by the debugger of FIG. 2.

FIG. 6 is a remove breakpoint routine executed by the debugger of FIG.2.

FIG. 7 is an illustrative example of an object-oriented computer programhaving a class defining multiple creators.

DETAILED DESCRIPTION

The embodiments illustrated hereinafter facilitate the debugging ofobject-oriented computer programs by tracking the execution of amultiple creators for classes defined in such computer programs.Typically, such tracking occurs through the use of “creation”breakpoints that permit tracking of multiple creators to be managed in acollective manner. Creators are typically implemented via constructormethods in many object-oriented programming environments, although it isenvisioned that other environments may utilize default or other creatorsthat are not explicitly defined by a programmer, but rather areimplicitly defined. In still other environments, no methods may becalled in response to creation of an object. Nonetheless, it may bebeneficial to define this default condition, in which no method ascalled, to be analogous to one “creator” for the class.

Creation breakpoints typically have associated therewith multiplebreakpoints that are set on the various creators for a particular class,and typically on specific statements within such creators. Moreover, themultiple breakpoints are typically managed in a collective mannerthrough user interaction with a creation breakpoint, e.g., so that thebreakpoints can be collectively set or removed in response to particularuser input, rather than being managed individually through userinteraction with each breakpoint. While some environments may supportinteraction with individual breakpoints associated with a creationbreakpoint, in the embodiments discussed hereinafter, the individualbreakpoints are essentially hidden from the user (e.g., a programmer,developer, program tester, etc.) such that only interaction with thecreation breakpoint itself is principally supported.

In other embodiments, the multiple breakpoints used to track themultiple creators are not associated with a common creation breakpoint.In such embodiments, however, the automated functionality describedherein typically facilitates the setting of the multiple breakpoints byvirtue of the automated nature in which creators can be identified (andoptionally presented to a user for selection), and breakpoints may becollectively set.

Moreover, as will be discussed in greater detail below, the embodimentsdescribed herein also facilitate tracking of object creations viamultiple creators, typically via maintaining a common counter that isincremented in response to hitting any of the breakpoints set on themultiple creators. The counter, as well as a condition that triggers ahalting of execution based upon the state of the counter, are typicallymaintained in association with a creation breakpoint. However, it willbe appreciated that, in other embodiments, object creation trackingacross multiple creators may not require the utilization of a creationbreakpoint and/or the utilization of breakpoints that are set onindividual creators for a class.

Turning now to the Drawings, wherein like numbers denote like partsthroughout the several views, FIG. 1 illustrates a computer system 10suitable for utilizing creation breakpoints consistent with theinvention. Computer system 10 is shown for a multi-user programmingenvironment that includes at least one processor 12 that obtainsinstructions or op codes, and data via a system bus 14 from a mainmemory 16. Computer system 10 may be implemented as a PC-based server, aminicomputer, a midrange computer, a mainframe computer, etc. In otherembodiments, however, computer system 10 may be implemented usingpractically any other type of computer or programmable electronicdevice, including single-user computers such as desktop computers,laptop computers, handheld computers, etc.

Processor 12 may represent one or more processors (e.g.,microprocessors), and memory 16 may represent the random access memory(RAM) devices comprising the main storage of computer system 10, as wellas any supplemental levels of memory, e.g., cache memories, non-volatileor backup memories (e.g., programmable or flash memories), read-onlymemories, etc. In addition, memory 16 may be considered to includememory storage physically located elsewhere in computer system 10, e.g.,any cache memory in a processor 12, as well as any storage capacity usedas a virtual memory, e.g., as stored on a direct access storage device38 or on another computer coupled to computer system 10 via a network46. Furthermore, practically any interconnect architecture, orcollection of interconnect architectures, may be used to implementsystem bus 14 consistent with the invention.

Memory 16 is shown having resident therein an operating system 18, anobject-oriented user program 20, and a programming environment 22 (e.g.,an Integrated Development Environment (IDE)). The programmingenvironment 22 typically provides tools for creating, editing, compilingand debugging the user program 20.

As such, among the tools supported by programming environment 22 is adebugger 24 that monitors and interfaces with program execution todiagnose the user program 20. The debugger 24 includes a user interface26, a program inspector 28, an execution environment 30, a breakpointmanager 32, a breakpoint table 34, and a creation counter 35, the useand configuration of each of which is described in greater detail below.

In the illustrated embodiment, the debugger 24 is illustrated as beingresident on the same platform upon which the user program 20 runs. Inother embodiments, however, a debugger may be resident on a differentplatform than a programming and/or execution environment, e.g., whendebugging embedded systems, or debugging server-based programs, on aprogrammer's workstation.

FIG. 1 also illustrates that computer system 10 also may include variousinterfaces for coupling the computer system to various external devices.For example, a mass storage interface 36 interfaces computer system 10to one or more mass storage devices 38, e.g., a direct access storagedevice (DASD). In addition, a terminal interface 40 interfaces computersystem 10 to one or more terminals or workstations 42, and a networkinterface 44 interfaces computer system 10 to one or more networks 46.Any number of alternate computer architectures, incorporating othercollections of external devices, may be used in the alternative.

The discussion hereinafter will focus on the specific routines utilizedto implement the herein-described debugger functionality. In general,the routines executed to implement the embodiments of the invention,whether implemented as part of an operating system or a specificapplication, component, program, object, module or sequence ofinstructions, or even a subset thereof, will be referred to herein as“computer program code,” or simply “program code.” Program codetypically comprises one or more instructions that are resident atvarious times in various memory and storage devices in a computer, andthat, when read and executed by one or more processors in a computer,cause that computer to perform the steps necessary to execute steps orelements embodying the various aspects of the invention.

Moreover, while the invention has and hereinafter will be described inthe context of fully functioning computers and computer systems, thoseskilled in the art will appreciate that the various embodiments of theinvention are capable of being distributed as a program product in avariety of forms, and that the invention applies equally regardless ofthe particular type of signal bearing media used to actually carry outthe distribution. Examples of signal bearing media include but are notlimited to recordable type media such as volatile and non-volatilememory devices, floppy and other removable disks, hard disk drives,magnetic tape, optical disks (e.g., CD-ROM's, DVD's, etc.), amongothers, and transmission type media such as digital and analogcommunication links.

In addition, various program code described hereinafter may beidentified based upon the application within which it is implemented ina specific embodiment of the invention. However, it should beappreciated that any particular program nomenclature that follows isused merely for convenience, and thus the invention should not belimited to use solely in any specific application identified and/orimplied by such nomenclature. Furthermore, given the typically endlessnumber of manners in which computer programs may be organized intoroutines, procedures, methods, modules, objects, and the like, as wellas the various manners in which program functionality may be allocatedamong various software layers that are resident within a typicalcomputer (e.g., operating systems, libraries, API's, applications,applets, etc.), it should be appreciated that the invention is notlimited to the specific organization and allocation of programfunctionality described herein.

The principal components in debugger 24 are illustrated in FIG. 2,showing the relationship between each of these components and userprogram 20. User interface 26 provides the mechanism through which userinput may be received from a user, as well as the mechanism throughwhich information such as debugging information can be presented to theuser. Program inspector 28 is used to derive important information abouta program, e.g., what are the constructors or creators for a particularclass of object.

Execution environment 30, which in the illustrated implementation isconsidered part of debugger 24, provides the underlying platform throughwhich user program 20 is executed in the debugger. In otherapplications, the execution environment may be implemented in a separateapplication that is interfaced with the debugger.

Breakpoint manager 32 provides breakpoint management functionality fordebugger 24, and it is within this module that much of the creationbreakpoint functionality is implemented in the illustrated embodiment.It will be appreciated that a wide variety of other debugging tools mayalso be incorporated into debugger 24, including, for example, supportfor watches (allowing a user to see the current value for a particularvariable), code stepping (allowing the user to execute a single line orinstruction at a time), etc. These additional functions have beenomitted from FIG. 2, however, as they are not particularly relevant toan understanding of the use of creation breakpoints consistent with theinvention.

In the illustrated embodiment, breakpoint manager 32 supportsconventional statement-based breakpoints, as well as creationbreakpoints consistent with the invention. Moreover, any type ofbreakpoint may be associated with a condition, as is well known in theart. Included within the breakpoint manager is typically functionalityfor setting breakpoints, removing breakpoints, and processingbreakpoints when they are hit while the object-oriented program isexecuted in the execution environment. Creation breakpoints consistentwith the invention may be implemented more or less as extensions toconventional breakpoints in the illustrated embodiment. However, inother embodiments, creation breakpoints may be handled completelyseparately from conventional breakpoints.

As is also shown in FIG. 2, one or more creation counters 35 may beaccessible by the execution environment to log or track the number ofcreations of various types of objects. As will be discussed in greaterdetail below, as an alternative to utilizing separate creation counters,the creation counters may be stored within breakpoint table 34 andassociated with the particular creation breakpoints defined therein.

Now turning to FIG. 3, an exemplary implementation of breakpoint table34 is illustrated in greater detail. Breakpoint table 34 includes aplurality of entries 50, each including a plurality of fields 52-68. Inthe illustrated implementation, breakpoint table 34 defines bothconventional-type breakpoints, as well as creation breakpointsconsistent with the invention.

Fields 52, 54, 56 and 58 respectively store the class, file name, sourcecode line number, and executable code address that identify a specificbreakpoint, and that provide a mapping between the location of thebreakpoint in the source code and in the executable code, e.g., so theappropriate source code may be displayed in response to hitting thebreakpoint during execution of the executable code. It should beappreciated that other combinations of identifiers may be utilized toidentify the position of each breakpoint in the source and/or executablecode.

Field 60 stores an optional condition to be associated with abreakpoint, and field 62 stores one or more actions to be performed inresponse to hitting the breakpoint, e.g., initiating a trace operation,halting execution, displaying debug information, logging debuginformation to a file or socket, etc. Various additional types ofconditions and resulting actions are well understood in the art.

Field 64 identifies whether the breakpoint is a creation breakpoint. Ifnot set, it is assumed that the breakpoint for a given entry is aconventional-type breakpoint. Otherwise, if field 64 is set to indicatea creation breakpoint, the entry is treated as a creation breakpoint,and additional fields 66, 68 are utilized in association therewith.

In particular, field 66 provides a pointer to a creator list 70, whichincludes a plurality of entries 72, 74 that are associated with specificcreators for a particular class. Each entry 72, 74 includes a creatorfield 76 that identifies the creator associated with the entry. Eachentry also includes fields 78, 80 and 82, which respectively store thefile name, source code line number, and executable code address of astatement in the creator upon which a breakpoint is set for thatcreator. Field 84 stores whether the particular creator is selected bythe user, i.e., whether the creator is being actively monitored forbreakpoint hits. In the alternative, field 84 may be omitted, with theassumption being that each entry listed in list 70 is an active creator.In the configuration shown in FIG. 3, however, creators that exist for aparticular class, but which are not monitored for hits thereto, arestill listed, but are essentially ignored during execution.

In addition, as shown in FIG. 3, each entry 50 in the breakpoint table34 may also include an optional counter field 68, which is used to storea creation counter for a creation breakpoint. Maintenance of a counterin breakpoint table 34 is an alternative implementation to the use of aseparate creation counter 35 as shown in FIG. 2. Either implementationmay be used in various embodiments consistent with the invention.

As may be appreciated from FIG. 3, creation breakpoint table 34 presumesthat all of the creators for a particular class are defined in thatclass. In other embodiments, however, creators that have not beenoverridden from any super classes of a particular class may also beincorporated into the creator list for a particular creation breakpoint.In such an instance, it may be desirable to include a class field ineach entry 72, 74 of creator list 70.

It will be appreciated that a wide variety of alternate data structuresmay be utilized to store the breakpoint information utilized inconnection with creation breakpoints consistent with the invention.Therefore, the invention is not limited to the particular datastructures described herein.

To implement creation breakpoints consistent with the invention, anumber of routines are supported by breakpoint manager 32 of FIG. 2.FIG. 4, for example, illustrates a set breakpoint routine 100, which isutilized to set a breakpoint in the debugger 24 via interaction by auser through user interface 26 (FIG. 2). Routine 100 may be initiatedvia any number of user input operations, e.g., via a graphical userinterface control such as a button, menu, pop-up menu, etc., or via acommand line command, a keystroke combination, or other user inputoperation known in the art.

Routine 100 begins in block 102 by determining whether the user hasindicated a desire to set a creation breakpoint. If not, control passesto block 104, where a conventional breakpoint is set in a manner knownin the art. Otherwise, block 102 passes control to block 106 to add thecreation breakpoint, by adding an entry to breakpoint table 34 for thecreation breakpoint. Next, block 108 determines whether the creationbreakpoint is a conditional breakpoint. If so, control passes to block110 to add a condition based upon user input, e.g., by storing thecondition in the entry for the creation breakpoint in breakpoint table34.

Any type of condition commonly utilized in connection with breakpointsmay be utilized as a condition for a creation breakpoint consistent withthe invention. Moreover, a creation breakpoint may also incorporate acounter condition whereby the total number of hits to a particular classof object may be tracked across multiple creators. As such, byspecifying a particular number of creations and/or an operator, a usermay specify that a creation breakpoint be triggered only upon meeting aparticular condition. As an example, one possible condition would bethat the total number of object creations meets or exceeds apredetermined threshold.

If a conditional breakpoint is not specified, or after a specifiedcondition has been added to the creation breakpoint entry, controlpasses to block 112 to obtain the selected class with which to associatethe creation breakpoint. Next, in block 114, the creators for theselected class are identified, e.g., by utilizing program inspector 28of debugger 24 to obtain the list of creators (optionally includingthose in a super class) for the selected class.

For example, in a Java programming environment, program inspector 28 mayuse Java reflection API's, the use and configuration of which are knownin the art. In other embodiments, other mechanisms may be used todetermine what creators exist for a particular class. In addition,inheritance concepts may be utilized in connection with the creationbreakpoints described herein, e.g., as described in U.S. patentapplication Ser. No. 09/998,511, filed on Nov. 30, 2001 by Jeremy AlanArnold et al., entitled “INHERITANCE BREAKPOINTS FOR USE IN DEBUGGINGOBJECT-ORIENTED COMPUTER PROGRAMS,” (ROC920010096US1) which applicationis incorporated by reference herein.

Next, block 116 determines whether the user has specified that only asubset of the creators are to be associated with the creationbreakpoint. If so, control passes to block 118 to present a list ofcreators to the user for selection thereby. Block 120 then selects thecreators based upon the selections made by the user. Returning to block116, if the user has not specified to only associate a subset ofcreators with a creation breakpoint, control passes directly to block122 to select all creators for inclusion with the creation breakpoint.

Once the creators have been selected in block 120 or 122, control passesto block 124 to add a breakpoint for each selected creator, wherebyroutine 100 is then complete.

To implement block 124, conventional-type breakpoints are typicallyadded at specific locations in each creator. However, unlikeconventional breakpoints, the breakpoints set on each creator are storedin a creator list 70, rather than as separate entries in breakpointtable 34. As far as interaction with an object-oriented user program,however, typically the addition of a breakpoint for each selectedcreator occurs in much the same manner, whereby either a branchinstruction to debugger program code, or alternatively an invalidinstruction that triggers an exception, is typically inserted into theuser program at the specified location. Other manners of modifying auser program to incorporate breakpoints on a temporary basis may also beused in the alternative.

In the illustrated implementation, the individual breakpoints associatedwith a creation breakpoint are typically set on a particular statementin each creator, e.g., the first statement. Other statement-basedbreakpoints, as well as non-statement-based breakpoints that areassociated with the creators themselves, may be used in the alternative.

Moreover, it should be appreciated that the population of data inbreakpoint table 34 may occur in a number of manners consistent with theinvention. For example, entries for each creator may be added to creatorlist 70 in block 114 of FIG. 4, with the selected field 84 for eachentry modified in blocks 122 and 120 as appropriate. In addition, fields78-82 may only be modified in block 124 for those selected creators. Inthe alternative, each creator may have a breakpoint set thereon even ifthe creator is not selected, with functionality in the debugger utilizedto ignore the breakpoint if it is determined that the creator with whichit is associated is not selected.

Moreover, the manner in which a user may supply the user input for eachof the operations illustrated in FIG. 4 may vary in differentembodiments. For example, a user may be presented with a dialog box uponrequesting that a creation breakpoint be created for a particular class(e.g., by right-clicking on a class definition and selecting anappropriate menu entry on the pop-up menu that is displayed as a resultthereof). The dialog box may include, for example, fields for entering acondition, selecting or unselecting particular creators, etc. As such,it should be appreciated that the operations performed in routine 100may occur in different orders, e.g., a user may be presented with a listof creators initially upon requesting to create a creation breakpoint,and may be presented with the opportunity to specify a condition andselect all or a subset of the creators in the same dialog box, withselection of a “OK” button resulting in the generation of theappropriate breakpoint data. Other modifications and alternatives willbe apparent to one of ordinary skill in the art.

Once individual breakpoints are set for a particular creationbreakpoint, processing of breakpoints during debugging of a computerprogram proceeds in a similar manner to that for conventionalbreakpoints. FIG. 5, for example, illustrates a breakpoint hit routine130 that is executed whenever a breakpoint is hit during execution of acomputer program being debugged. Routine 130 begins in block 132 bydetermining whether the breakpoint is associated with a creationbreakpoint. This step may be performed, for example, by determiningwhether the breakpoint is in a creation list 70, or alternatively,supplied as a non-creation entry 50 in breakpoint table 34 (i.e., anentry 50 where the creation flag in field 64 is not set).

If the breakpoint is not a creation breakpoint, block 132 passes controlto block 134 to handle the breakpoint in a conventional manner.Otherwise, block 132 passes control to block 136 to increment thecounter associated with the creation breakpoint.

Next, block 138 processes any conditions associated with the creationbreakpoint. If no condition is specified, or if a condition is specifiedbut has not yet been satisfied, block 138 terminates without triggeringthe breakpoint. If no condition is specified (indicating that thecreation breakpoint is unconditional), or if the condition specified forthe breakpoint has been satisfied, control passes to block 140 to haltprogram execution and present debugger information associated with thecreation breakpoint, in a manner similar to conventional breakpoints.Any additional actions associated with the creation breakpoint may alsobe performed at this time.

Yet another operation that may be performed in connection with acreation breakpoint is the removal of the creation breakpoint once auser is satisfied that no further debugging with the creation breakpointis required. FIG. 6 illustrates a remove breakpoint routine 150 thathandles the removal of a creation breakpoint in a similar manner to aconventional breakpoint, with the exception that additional steps areperformed to clear the creator list for the creation breakpoint entry.

In particular, routine 150 begins in block 152 by determining whetherthe breakpoint to be removed is a creation breakpoint. If not, thebreakpoint entry therefor is removed from breakpoint table 34 in aconventional manner, as shown in block 154. If, however, the breakpointis a creation breakpoint, prior to removing the breakpoint entry, thecreator list 70 is removed as well, as shown in block 156.

Therefore, it will be appreciated that, through the utilization of acreation breakpoint entity, multiple breakpoints associated withmultiple creators can be managed collectively, i.e., set and/or removedas a group. Thus, a user is often freed from the burden of setting orremoving individual breakpoints to or from particular creators.Moreover, as illustrated above in connection with FIG. 5, a counter canbe incremented for each creation of an object of a particular class,regardless of the creator being used to create that object.

As an example of the operation of debugger 24, FIG. 7 illustrates in awindow 180 a portion of a computer program 190 including a classdefinition 192. As shown in FIG. 7, class 192 includes two constructormethods, or creators, defined at lines 2-4 and 5-7, respectively. Forthe purposes of illustration, class 192 is illustrated as aJava-compatible program. The creator defined at lines 2-4 is a defaultconstructor method having a call signature of “MyClass( )”, and thecreator defined at lines 5-7 is another constructor method having a callsignature of “MyClass(int)”, which differs from the default constructormethod in that it accepts a single integer argument i.

In the exemplary program 190, the main( ) method defined in the programcreates eleven “MyClass” objects, with six of those objects createdusing the default constructor method “MyClass( )”, and five of theobjects created using the alternate constructor method “MyClass(int)”.Suppose, however, that the programmer that developed the main( ) methodintended that the main loop execute ten times, rather than the eleventimes. For example, suppose the programmer intended the terminatingcondition for the FOR loop to be “i<10” rather than “i<=10” as is shownin FIG. 7.

Creation breakpoints consistent with the invention may be utilized in anumber of manners to catch this programming error. For example, anunconditional creation breakpoint could be set on the MyClass( ) class,and with “all creators” specified such that individual breakpoints willbe set on each constructor method. During execution while under debug,the creation breakpoint would be triggered eleven times, once for eachcreation of a “MyClass( )” instance. Were the programmer to manuallycount the number of times the creation breakpoint is hit, the programmerwould be able to determine that the breakpoint was hit eleven times,rather than the intended ten times, and take appropriate correctiveaction thereafter.

In the alternative, the programmer could set a conditional creationbreakpoint on the “MyClass” class, specifying that all creators betracked, and specifying a condition that triggers the breakpoint if thenumber of “MyClass” instances is greater than or equal to ten.

FIG. 3, for example, illustrates the resulting entry 50 that might becreated in response to a user request to set the aforementionedconditional creation breakpoint on the “MyClass” class. In thisinstance, the class and file name fields 52, 54 for the entry specifythe class and file name within which the class is defined. As entry 50defines a creation breakpoint, however, typically fields 56 and 58 arenot used, and would thus are left blank. Also, since a user hasspecified a condition, that condition is stored in field 60 as shown inFIG. 3, and any desired actions are indicated in field 62. Field 64specifies that the breakpoint is a creation breakpoint, and creator listfield 66 points to the creator list 70 shown in FIG. 3. Field 68 isinitially set at an initial null value prior to execution of the programunder debug.

Within creator list 70 are entries 72, 74, each associated with aparticular creator defined in the class. Entry 72 is associated with thedefault constructor method “MyClass( )”, which is identified in field 76for the entry. Field 78 stores the file name for the creator, and fields80 and 82 respectively store the source code line number and executablecode address of the precise statement with which the breakpoint for thatentry is associated. Similar information for the “MyClass(int)”constructor method is stored in entry 74. Field 84 for each entry 72, 74also indicates that the creator is selected, as in this example it ispresumed that the programmer has requested to track all creators.

Under this scenario, during execution under debug, the creationbreakpoint would be reached two times, upon the tenth and eleventhcreations of a “Myclass” object. Thus, if a programmer discovered thathe or she was creating more “Myclass” objects than expected, theprogrammer could use conventional debugging techniques to step throughthe code after the tenth creation to find out why an eleventh creationwas occurring, and correct the error as appropriate.

Various modifications may be made to the illustrated embodiments withoutdeparting from the spirit and scope of the invention. For example, thebreakpoints with which a creation breakpoint is associated may be set oncreators as a whole, rather than on specific statements in thosecreators. Also, creation breakpoints may be handled completelyseparately from conventional-type breakpoints, and may not rely uponconventional-type breakpoints within each creator of a particular class.

Other modifications will be apparent to one of ordinary skill in the arthaving the benefit of the instant disclosure. Therefore, the inventionlies in the claims hereinafter appended.

1. A computer-implemented method of debugging an object-orientedcomputer program, the method comprising: in response to user input,setting a creation breakpoint for a class defined in the object-orientedcomputer program, wherein setting the creation breakpoint includes:identifying a plurality of creators for the class; setting a pluralityof breakpoints on the identified creators; adding an entry for thecreation breakpoint in a breakpoint data structure; storing breakpointinformation for each of the plurality of breakpoints in the breakpointdata structure; and associating the breakpoint information for each ofthe plurality of breakpoints with the entry in the breakpoint datastructure for the creation breakpoint to associate each of the pluralityof breakpoints with the creation breakpoint; determining that thecreation breakpoint has been hit during debugging by detecting hittingof any of the plurality of breakpoints, wherein the creation breakpointis determined to be hit only in response to detecting hitting of abreakpoint set on an identified creator for the class; and haltingexecution of the object-oriented computer program during debugging inresponse to determining that the creation breakpoint has been hit. 2.The method of claim 1, wherein identifying the plurality of creatorsincludes identifying every creator for the class.
 3. The method of claim1, further comprising, after identifying the plurality of creators,displaying a list of the identified creators and receiving user input toselect a subset of identified creators, wherein the plurality ofbreakpoints are set on only the subset of the identified creators. 4.The method of claim 1, wherein the plurality of breakpoints arecollectively set on all of the identified creators in response to theuser input.
 5. The method of claim 1, wherein setting the plurality ofbreakpoints includes setting each breakpoint from the plurality ofbreakpoints on a statement in one of the identified creators.
 6. Themethod of claim 5, wherein setting each breakpoint includes insertingdebugging program code in the creator on which such breakpoint is set.7. The method of claim 1, further comprising tracking a total number ofhits to the plurality of breakpoints, wherein halting execution of theobject-oriented computer program during debugging in response todetermining that the creation breakpoint has been hit includes:determining whether the total number of hits meets a condition inresponse to hitting any of the plurality of breakpoints, wherein thecondition is the total number of hits meeting or exceeding a threshold,and wherein the total number of hits includes at least one hit from atleast two different breakpoints; and halting execution of theobject-oriented computer program if the total number of hits meets thecondition.
 8. The method of claim 1, wherein each creator comprises aconstructor method defined in the class.
 9. The method of claim 1,further comprising collectively removing the creation breakpoint and theplurality of breakpoints in response to user input.
 10. The method ofclaim 1, wherein storing breakpoint information for each of theplurality of breakpoints in the breakpoint data structure comprisesadding an entry for each breakpoint to a creator list associated withthe creation breakpoint.
 11. An apparatus, comprising: a memory withinwhich resides at least a portion of an object-oriented computer program;and program code configured to debug the object-oriented computerprogram by: in response to user input, setting a creation breakpoint fora class defined in the object-oriented computer program, wherein settingthe creation breakpoint includes: identifying a plurality of creatorsfor the class; setting a plurality of breakpoints on the identifiedcreators; adding an entry for the creation breakpoint in a breakpointdata structure; storing breakpoint information for each of the pluralityof breakpoints in the breakpoint data structure; and associating thebreakpoint information for each of the plurality of breakpoints with theentry in the breakpoint data structure for the creation breakpoint toassociate each of the plurality of breakpoints with the creationbreakpoint; determining that the creation breakpoint has been hit duringdebugging by detecting hitting of any of the plurality of breakpoints,wherein the creation breakpoint is determined to be hit only in responseto detecting hitting of a breakpoint set on an identified creator forthe class; and halting execution of the object-oriented computer programduring debugging in response to determining that the creation breakpointhas been hit.
 12. The apparatus of claim 11, wherein the program code isconfigured to identify the plurality of creators by identifying everycreator for the class.
 13. The apparatus of claim 11, wherein theprogram code is further configured to, after identifying the pluralityof creators, display a list of the identified creators and receive userinput to select a subset of identified creators, wherein the pluralityof breakpoints are set on only the subset of the identified creators.14. The apparatus of claim 11, wherein the plurality of breakpoints arecollectively set on all of the identified creators in response to theuser input.
 15. The apparatus of claim 11, wherein the program code isconfigured to set the plurality of breakpoints by setting eachbreakpoint from the plurality of breakpoints on a statement in one ofthe identified creators.
 16. The apparatus of claim 11, wherein theprogram code is configured to track a total number of hits to theplurality of breakpoints, determine whether the total number of hitsmeets a condition in response to hitting any of the plurality ofbreakpoints, and halt execution of the object-oriented computer programif the total number of hits meets the condition, wherein the conditionis the total number of hits meeting or exceeding a threshold, andwherein the total number of hits includes at least one hit from at leasttwo different breakpoints.
 17. The apparatus of claim 11, wherein theprogram code is further configured to collectively remove the creationbreakpoint and the plurality of breakpoints in response to user input.18. The apparatus of claim 11, wherein the program code is furtherconfigured to store breakpoint information for each of the plurality ofbreakpoints in the breakpoint data structure by adding an entry for eachbreakpoint to a creator list associated with the creation breakpoint 19.A program product, comprising: program code configured to debug anobject-oriented computer program by: in response to user input, settinga creation breakpoint for a class defined in the object-orientedcomputer program, wherein setting the creation breakpoint includes:identifying a plurality of creators for the class; setting a pluralityof breakpoints on the identified creators; adding an entry for thecreation breakpoint in a breakpoint data structure; storing breakpointinformation for each of the plurality of breakpoints in the breakpointdata structure; and associating the breakpoint information for each ofthe plurality of breakpoints with the entry in the breakpoint datastructure for the creation breakpoint to associate each of the pluralityof breakpoints with the creation breakpoint; determining that thecreation breakpoint has been hit during debugging by detecting hittingof any of the plurality of breakpoints, wherein the creation breakpointis determined to be hit only in response to detecting hitting of abreakpoint set on an identified creator for the class; and haltingexecution of the object-oriented computer program during debugging inresponse to determining that the creation breakpoint has been hit; and asignal bearing medium bearing the program code.
 20. The program productof claim 19, wherein the signal bearing medium includes at least one ofa transmission medium and a recordable medium.